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File System Questionnaire 


As noted in RFC #164 (page 35), a subcommittee of the NWG, under the 
chairmanship of Abhay Bhushan, is currently generating proposals for a 
"data transfer protocol" and a "file transfer protocol". 


The subcommittee has decided that the file transfer protocol should 
provide standard methods for requesting the transfer of a file but 
should not, at this time, attempt to standardize file naming 
conventions, access control conventions, and the like. Thus a user 
who is, for example, trying to store a file on a remote Host will be 
required to use the file naming conventions appropriate to the remote 
Host. 


Given the above point of view, it becomes imperative for users to have 
some source of information about Host file conventions. Such 
information, once compiled, will also serve as input to possible 
standardization efforts of the file transfer subcommittee. For this 
reason Abhay has asked me to solicit information on file conventions 
from the Host organizations. What follows is a description of the 
kinds of information of interest. I am well aware of the fact that 
many of you are tired of writing system descriptions; Xerox copies of 
short sections of your local documentation are fine if the result is 
complete and comprehensible. (In the case that your Host will never 
permit network use of your file system, a note to that effect would be 
sufficient.) 


Information Requested 


1. File naming conventions - We (loosely) define a pathname to be 
the data string which must be input to the file system by a user 
(a network user if your system makes a distinction between local 
and network users) in order to identify a file. We are interested 
in syntax, semantics, and defaults. Typical components of pathnames 
are: 


- "device" fields 

—- user names 

— version numbers 

—- index names 

— punctuation marks 


[Page 1] 


Common types of defaults are: 


- device is disk 
- version number is largest in system 


For hierarchical file structures, descriptions may be fairly 
complex, but with lots of defaults; in such cases an illustration 
of a "normal" pathname might be helpful. 


Access control mechanisms - Access control mechanisms range from 
simply knowledge of a file’s pathname to elaborate hierarchies 
of group-project-task-username membership with passwords and 
separate controls for reading and writing. There are two 
aspects of the access control mechanism which are of interest: 


a. A description of what inputs the user should give the file 
system, both at the time of file creation and at the time of 
retrieval, in order to define the permitted modes of access 
and to gain access. What are the syntax and semantics of 
these inputs? 


b. A description of the ways in which the access control 
mechanism is designed to help (or hinder) the sharing of 
files. For example, may two users "Simultaniously" update a 
given file? May the creator of the file define a set of 
authorized users to the file system (and how)? Is it possible 
to define different access controls for various subunits of a 
given file? 


Directories - Many systems maintain file directories which are 
designed to be helpful to the user. A directory might, for 
example, provide a list of all files created by a particular 
individual, along with some information regarding file size, 

file structure, access controls, etc. In general, such systems 
allow the user to input a pathname and retrieve the directory to 
which that pathname refers. Aspects of the directory structure of 
interest are: 


a. What are the syntax and semantics of a directory pathname? 


b. What use is a directory, i.e., what type of information 
does the directory contain? 


c. What access controls are used for access to the directories? 
For example, must a user supply a password in order to 
retrieve a directory, and is this password typically the same 
as the password he would use to retrieve a file listed in that 
directory. 
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Commands and functions of the file system - A general description 
of what the file system is designed to do would be useful. For 
example, the system might simply accept an entire file and store 
it sequentially on a tape; with the only mode of retrieval being 
to retrieve the entire file. On the other hand, the system might 
provide the ability to access any "subfield" with a unique 
pathname. Perhaps there is the ability to restructure a file, 
change the access control, delete all the fields associated with a 
directory, etc. We realize that this aspect of the file system 
begins to overlap the area of "data management", which is the 
responsibility of another subcommittee; therefore, use your 
judgement as to what functions are an intrinsic aspect of the 
file-handling system and which are aspects of "data-management". 


Internal representation and I/O modes - The remote user of a file 
system will normally be interested in internal representation of 
data only insofar as that representation of data is reflected in 
the I/O interface between the file system and the network. For 
example, if all of the file system’s I/O is in 8-bit ASCII 
characters, then the user is unlikely to care if they are stored 
in ASCII, EBCDIC, or some other form. However, if an alternate 
transmission mode is available it may be useful; for example, 

two PDP-10’s, both of which store 5 characters and one "filler" 
bit per word, might find it advantageous to transfer information 
in this mode rather than converting between internal representation 
and 8-bit ASCII for each character. Other information on internal 
representation which would be of interest to the user might 
include (if applicable): 


- range of numeric data permitted 

- maximum text string lengths 

—- whether the user must indicate "record" boundaries on input 

- what "logical structure" information the user may specify 
for a new file, and what he must specify 

- whether the user must specify the file size before beginning 
input, and how he does it 


Undoubtedly, there will be aspects of each file system which don’t 
fit neatly into the categories above, but which users will find 
important or essantial in using the system. These should be 
identified and described if possible. 


Please address responses to this questionnaire to: 


Alex McKenzie 

Bolt Beranek and Newman Inc. 
50 Moulton Street 

Cambridge, Massachusetts 02138 
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If the questions above are confusing, don’t hesitate to call me for 
clarification at (617) 491-1850 ext. 441. I will issue another RFC 
summarizing the responses after I have received a significant number 


of them. 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Stefan Hinker 6/97 ] 
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